ICFP: G: Curry-Howard for Callbacks

Event-driven programming has become an increasingly popular programming model for lightweight concurrency. It has been used successfully in applications ranging from message-passing in Concurrent ML [10] to asynchronous I/O operations in Node.js [11] to the dynamic behavior of GUIs in eXene [3], among many others. The unifying idea is that an event is a computation that executes independently from other events and can eventually return a value. Unfortunately, event-driven programming can be difficult because it is based on a combination of features that do not play well together: callbacks and state. Callbacks are higher-order first-class functions. When combined with stateful abstractions like Ivars in OCaml’s Async library [7] or Promises in Scala [5], the resulting programs can be convoluted and errorprone. Many event-driven languages have tried to alleviate this difficulty by introducing various abstractions for serializing and synchronizing events. Unfortunately this has been done in a somewhat ad hoc way, resulting in many competing abstractions formulated in slightly different ways. For example, while events in Go [1] and Lwt [12] are thought of as lightweight threads, in Scala they are thought of as write-once shared state in the form of Futures [5], and in Concurrent ML they are thought of as concurrent processes [10]. This work aims to understand the space of eventdriven programming by identifying the structures common to it with an intuitive perspective from temporal logic. Under this interpretation, an event is a computation that can eventually return a value, and so we identify its type with the “eventually” proposition A of temporal logic.